This should be documented so people using ASGI with Django realize they need to install these extra deps to make it work.

How do ASGI deps work with Django? Do regular Django projects need to install additional packages to make ASGI work or does Django now ship with (or depend on) bundled ASGI module. If some level of ASGI support is always present in Django now, may be we can add this as a main dependency instead?

This is a good discussion topic. Django doesn't require any additional/extra dependencies for ASGI to work (aside from running it using Uvicorn/Daphne), and bundles asgiref since the async introduction in Django 3.0: django/django@a415ce7#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7

This dependency doesn't include other heavy dependencies that aren't already required by opentelemetry-instrumentation-wsgi. However, we also have to consider that ASGI is only present since Django 3.x, while this project tries to maintain support for older Django versions.

I think the only missing change on this PR, if we go with adding this to install_requires, is to make _is_asgi_supported also depend on DJANGO_3_0 being True, as we won't receive any ImportError anymore when importing ASGI dependencies.

Can a django service/middleware handle both WSGI and ASGI requests at the same time? If it can only handle one kind, may be this can can run in middleware init and result can be stored in an instance variable.

At least is_asgi_supported can be called before _is_asgi_request and that way we can avoid running the type check for non-ASGI requests.

Can a django service/middleware handle both WSGI and ASGI requests at the same time?

Yes, it can handle both, so we need to check which kind of request we're receiving on each call.

At least is_asgi_supported can be called before _is_asgi_request and that way we can avoid running the type check for non-ASGI requests.

As we're using is_asgi_request multiple times on this method, I don't think we can avoid the type-check call.

• If ASGI is not supported, we need to know if the current request is ASGI.
• If ASGI is supported, we need to know it nevertheless, to decide on which carrier, carrier_getter, etc. to use.

We could also set a variable named carrier to request.scope or request_meta in the similar is_asgi_request check above and here just call the function on carrier

Good idea, applied!

we don't have to use extract_attribute_from_object. I think it'd be simpler to just write a dedicated extract function for Django ASGIRequest objects instead of doing all this just to be able to use the existing func.

Would it make more sense, to keep using the extract_attributes_from_object util, to go with a composition approach?

attributes = extract_attributes_from_object(
    request, self._traced_request_attrs, attributes
)
if is_asgi_request:
    # ASGI requests include extra attributes in request.scope.headers.
    attributes = extract_attributes_from_object(
        types.SimpleNamespace(**{
            name.decode("latin1"): value.decode("latin1")
            for name, value in request.scope.get("headers", [])
        }),
        self._traced_request_attrs,
        attributes,
    )

does add_response_attributes only set a status code? The name suggests it does more than that.

It does actually. It adds HTTP status code attribute in addition to setting status on the span. Plus is also has some additional logic which we miss out on here. Any reason we cannot just use that function for ASGI as well?

As the functions are right now, I don't see any needed changes for both WSGI and ASGI to make the same changes to the current span:

• WSGI:

  opentelemetry-python-contrib/instrumentation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py

  Lines 188 to 208 in e129174

  	def add_response_attributes(
  	span, start_response_status, response_headers
  	): # pylint: disable=unused-argument
  	"""Adds HTTP response attributes to span using the arguments
  	passed to a PEP3333-conforming start_response callable."""
  	if not span.is_recording():
  	return
  	status_code, _ = start_response_status.split(" ", 1)
  	try:
  	status_code = int(status_code)
  	except ValueError:
  	span.set_status(
  	Status(
  	StatusCode.ERROR,
  	"Non-integer HTTP status: " + repr(status_code),
  	)
  	)
  	else:
  	span.set_attribute(SpanAttributes.HTTP_STATUS_CODE, status_code)
  	span.set_status(Status(http_status_to_status_code(status_code)))

• ASGI:

  opentelemetry-python-contrib/instrumentation/opentelemetry-instrumentation-asgi/src/opentelemetry/instrumentation/asgi/__init__.py

  Lines 125 to 140 in e129174

  	def set_status_code(span, status_code):
  	"""Adds HTTP response attributes to span using the status_code argument."""
  	if not span.is_recording():
  	return
  	try:
  	status_code = int(status_code)
  	except ValueError:
  	span.set_status(
  	Status(
  	StatusCode.ERROR,
  	"Non-integer HTTP status: " + repr(status_code),
  	)
  	)
  	else:
  	span.set_attribute(SpanAttributes.HTTP_STATUS_CODE, status_code)
  	span.set_status(Status(http_status_to_status_code(status_code)))

HTTP status codes need to be translated to OpenTelemetry status codes before setting the span status e.g,

I also think this is already fixed in the current set_status_code implementation.